RichTextBox scrolling incorrect

[Peter Klakocer]

I use two RichTextBox controls with Visual Basic 6.0 US Enterprise with SP6.
To synchronize the horizontal scroll bars, I read the value of both with
EM_GETSCROLLPOS, overwrite the x value of the target with that of the source
and set the scrollbar of the target with EM_SETSCROLLPOS. The y value is
left unchanged.
When using the Font Courier New 10 (or Arial 10) with a text with more than
4095 lines, the target window shows a strange behaviour: Although the y
value is not changed, the window content jumps some lines down (scrolls
towards beginning).
With MS Sans Serif, all works fine, but I need a fixed typed font.

To reproduce that, please use a RTB with Courier New 10 and a text with more
than 4095 lines.
Scroll to any position, use EM_GETSCROLLPOS to get and EM_SETSCROLLPOS to
set the same value.
The window content will jump down.

Any ideas?

If there is an way to do only a horizontal scroll, please tell me.
(Seems like GetScrollInfo doesn't scroll the window content, only the
scrollbar.)

TIA
Peter

[Rick Rothstein]

I don't have an answer to your question, only an observation. Assuming
8-bits to a character, 4096 times 8 equals 32768 which exceeds by one
what a signed integer can hold. If that has anything to do with the
problem, it would explain the 4095 limit; however, it would not seem to
explain some fonts work and others don't. Actually, we're probably
talking about 4096 unicode characters which would mean 16 bits per
character and that would be 65536 which exceed what an unsigned integer
can hold (meaning the same 4095 limit that you found). As I said, it's
only an observation; hopefully someone who knows better will come along
and respond.

Rick - MVP

[Peter Klakocer]

Thank you for your quick response.

I know that the 4096 is a "magic border", but I have 4095 lines, not
characters.

The effect doesn't change with the number of characters, but changes with
the font size.

It looks like a rounding error (maybe when windows tries to ensure that the
window content starts with a vertical full visible line) that comes to a
value >1 above 4095 lines.

The error is approximately (line# - 4095), but not linear :-((

My last recent idea was to compare the vertical size of "MS Sans Serif 10"
and "Courier New 10", but they are identical with 240 twips (16 pixels, here
we are again: 4096*16 = 64k)

"Rick Rothstein" <rickNOS...@NOSPAMcomcast.net> wrote in message
news:e8c1gR3O...@tk2msftngp13.phx.gbl...

[Rick Rothstein]

> The effect doesn't change with the number of characters, but changes
with
> the font size.
>
> It looks like a rounding error (maybe when windows tries to ensure
that the
> window content starts with a vertical full visible line) that comes to
a
> value >1 above 4095 lines.
>
> The error is approximately (line# - 4095), but not linear :-((

[Thwap! - the sound of a hand slapping a forehead] Lines! You did say
lines, didn't you. Can't figure out why I thought you said characters.
Sorry.

> My last recent idea was to compare the vertical size of "MS Sans Serif
10"
> and "Courier New 10", but they are identical with 240 twips (16
pixels, here
> we are again: 4096*16 = 64k)

Yes, that is interesting. If you change the font size, does the
"maximum" number of lines change?

Just out of curiosity, what is in the two RichTextBoxes that you are
trying to sync them? They don't both contain the same text, do they?
Maybe if we know what you are doing, we might be able to devise a
work-around.

Rick - MVP

[Peter Klakocer]

Don't Panic! Lines, columns, characters, bytes - whats the difference :-))

Using a larger font, the number of lines decreases, but I have not yet
checked if the formular fontheight * lines = 64k matches. Will do it soon.

The application is a difference viewing tool for our version management that
interpretes and displays the diff output of Merant PVCS Version Manager in a
way defined in our ISO 9000 commitment. To get a textmarker-effect, I need
to colour the character background. For this, I used Edamno's RichEdit
control, but it lacks on performance with big files. Now I use the RichEdit
control from the vbaccelerator page, that offers a horizontal scroll event.
The sync of the two horizontal scrollbars is a feature very useful when
viewing longer lines or when using a larger font / lower screen resolution.

But the scrolling problem occurs in a native RTB, also. So I thought I drag
it down to this for this posting.
A "set horizontal scroll position" function call would help ...

"Rick Rothstein" <rickNOS...@NOSPAMcomcast.net> wrote in message

news:eugkj33O...@TK2MSFTNGP12.phx.gbl...

[Peter Klakocer]

Looks like the problem occurs if fontheight in pixels * line count > 64k
So this workaround seems to work for Courier New in all font sizes we use
Nasty, but working

lngLineHeightPixels = ScaleY(lblAutoSize.Height, vbTwips, vbPixels)
lngPixelCntY(Index) = lngLineHeightPixels * rtbDiff(Index).LineCount

------------------------------
Private Function CorrectScrollPosY(Index As Long, lngNewScrollPos As Long)
As Long

If (lngPixelCntY(Index) > 65535) Then
CorrectScrollPosY = CLng(CDbl(lngNewScrollPos) * 0.072282 *
lngLineHeightPixels)
Else
CorrectScrollPosY = lngNewScrollPos
End If

End Function

------------------------------
"Peter Klakocer" <k...@sat.co.at> wrote in message
news:uTX4gn1...@TK2MSFTNGP12.phx.gbl...

[Peter Klakocer]

Here is the universal function - we see, 65535 is present :-)

Private Function CorrectScrollPosY(Index As Long, lngNewScrollPos As Long)
As Long

If (lngPixelCntY(Index) > 65535) Then
CorrectScrollPosY = CLng(CDbl(lngNewScrollPos) *

lngLineHeightPixels * rtbDiff(Index).LineCount / 65535#)

Else
CorrectScrollPosY = lngNewScrollPos
End If

End Function

"Peter Klakocer" <k...@sat.co.at> wrote in message
news:ue7bHeBP...@TK2MSFTNGP09.phx.gbl...